The invention relates to computer system bus interfaces and, more particularly, to a mechanism for providing device status information during some types of bus read transactions.
Many current computer systems are designed around standard bus architectures such as the Peripheral Component Interface (PCI) standard. (See the "PCI Local Bus Specification, revision 2.1," available from the PCI Special Interest Group of Hillsboro, Oreg.). Selection of a bus architecture is tantamount to specifying a communication protocol by which disparate devices within the computer system are allowed to communicate.
In a PCI bus computer system, devices may be targets, initiators, or both targets and initiators. Initiators typically initiate bus transactions (e.g., read and write operations), while targets respond to initiator device initiated transactions. (For clarity, bus transactions are referenced from a initiator device's point of view. Thus, a read transaction signifies an initiator device is requesting data from a target device. Conversely, a write transaction signifies an initiator device is attempting to transfer data to a target device.)
Table 1 describes some of the bus transaction control signals used in a 32-bit PCI based computer system. Generally, an initiator initiates a bus transaction by asserting the FRAME# signal and then placing an address on the AD bus. The first rising clock edge after the FRAME# signal is asserted completes the address phase. Following the address phase, the first of one or more data phases begins during which data is transferred between initiator and target on each rising clock edge in which both the IRDY# and TRDY# signals are simultaneously asserted. Wait cycles may be inserted in a data phase by either the initiator device or the target device by deasserting the IRDY# or TRDY# signals respectively.
TABLE 1 Some PCI Bus Transaction Signals Signal Description CLK Clock provides timing for PCI transactions and is an input to all PCI devices. All of the following signals are sampled on the rising edge of CLK. Current PCI buses may operate at a clock of 33 or 66 megahertz (MHz). AD[31::0] Address and Data are multiplexed on the same PCI bus lines. A bus transaction consists of an address phase followed by one or more data phases. This collection of bus lines constitute the address/data bus, or AD bus. FRAME# Cycle Frame is driven by the current bus initiator to indicate the beginning and duration of a transaction. IRDY# Initiator Ready indicates the current bus initiator is ready and able to complete a data phase of the current transaction. During a read transaction, IRDY# indicates the initiator is prepared to accept data. During a write transaction, IRDY# indicates that valid data is present on AD[31::0]. TRDY# Target Ready indicates the target is ready and able to complete a data phase of the current transaction. During a read transaction, TRDY# indicates that valid data is present on AD[31::0]. During a write transaction, TRDY# indicates the target is prepared to accept data. STOP# Stop indicates the current target is requesting the current initiator to stop the current transaction. DEVSEL# Device Select indicates a device has decoded its address as the target of the current transaction Note: In accordance with the PCI specification, the symbol `#` denotes a signal that is active (asserted) at a low logic level.
The timing diagram for a basic PCI read transaction is shown in FIG. 1. As indicated above, read transaction 100 begins with address phase 102 which, in turn, follows assertion of FRAME# signal 104 by the initiator device. During address phase 102 the AD bus (i.e., signals AD[31::0] 106) contains the address of the initiator device's intended target device. The initiator device indicates it is able to accept data from the target device by asserting IRDY# signal 108. Following address phase 102, the PCI specification requires turnaround cycle 110 during which the AD bus is not driven (this ensures the AD bus is not driven by both an initiator and target device at the same time).
The first rising clock edge following address phase 102 begins data phase 1112. In accordance with the PCI specification, the target device drives the AD bus following turnaround cycle 110 when DEVSEL# signal 114 is asserted--in this instance, following the rising edge of clock 3. The target must continue to drive the AD bus until the transaction completes (i.e., when the initiator deasserts FRAME# signal 104 following clock 7). Following assertion of DEVSEL# 114 and TRDY# 116 signals, data is transferred on each rising clock edge when both IRDY# 108 and TRDY# 116 signals are asserted, for example, on rising clock edges 4, 6, and 8. On the other hand, if either IRDY# 108 or TRDY# 116 signals are deasserted, a wait cycle is inserted into read transaction 100 and no data is transferred. For example, wait cycles may be inserted during clock cycles 3, 5, and 7.
The initiator knows that the final data will be transferred during data phase 3118 and so can deassert FRAME# signal 104 following data phase 2's 120 data transfer. On completion of read transaction 100, the initiator may place the PCI bus in an idle state by ensuring that both FRAME# 104 and IRDY# 108 signals are deasserted at the same time (not necessarily simultaneously), for example following data phase 3118.
In a PCI environment, either an initiator or target device may terminate a bus transaction. Initiator device terminated transactions are referred to as completion and timeout transactions. Target device terminated transactions are referred to as disconnect, target-abort, and retry transactions.
A retry transaction refers to the termination of a read transaction before any data is transferred. Consequently, retry transactions may indicate that a target device is creating a data transfer bottleneck thereby reducing a computer system's effective operating speed. Alternatively, retry transactions may indicate a delayed read or transaction ordering operations. It is generally not possible to accurately determine what is causing a retry transaction. That is, internal target device status information is typically opaque to other bus devices.
Thus, there is a need for a mechanism that a target device causing a retry transaction may use to provide information regarding the target's status without further impeding ongoing data transfer operations. The supplied information may, for example, be used to determine the cause of the retry operations.